Simple Redistribution Step-by-Step

We’re going to take our basic topology from the previous post Understanding Redistribution Part I , and configure to provide full connectivity between all devices with the most simple configuration. Then we are going to tweak some settings and see how they affect redistribution and optimal routing. This is going to be an introductory example to illustrate the redistribution control techniques mentioned previously.

First, we configure IGP routing per the diagram, and advertise Loopback0 interfaces (150.X.Y.Y/24, where X is the rack number, and Y is the router number) into IGP. Specifically, R2, R3 and R4 Loopbacks are advertised into OSPF Area 0. R5 and R6 Loopbacks are advertised into EIGRP 356 and R1 Loopback interface is simply advertised into EIGRP 123.

Next, we propose OSPF to be the core routing domain, used as transit path to reach any other domains. All other domains, in effect, will be connected as stub (non-transit) to the core domain. We start with EIGRP 123 and OSPF domains, and enable mutual redistribution between them on R2 and R3 routers:

Full article here

I am very interested on what Ethan Banks blogs about when he returns from his boot camp with Narbik next week. I started thinking about boot camps a few weeks ago and I’m seriously considering it. Since I have the Internetwork Expert End to End R&S self paced program, I have an option of purchasing the five day live boot camp for $1995. I am wondering if it would be best to stick with Internetwork Expert for all my training since that is what I have grown accustomed to. Also, right now Narbik’s boot camps are running $2000 as well. Not sure how long he will keep his prices at that mark. I was thinking maybe another voice would help as well. I do have some of his workbooks here, but have not gone over them.

Another thing to consider is the money. Is spending another $2000 wise with a baby on the way? I have the money for the boot camp, but a big thing to consider is the air fare and the hotel stay along with anything else. I could see this becoming a $3000 to $3500 trip quickly.

I need to figure this one out soon since the boot camps seem to fill up fairly quickly months ahead of time. I would like to have this off my “to do” list so I can concentrate more on the workbooks. Since my lab is scheduled for July 14th I was hoping to catch a lab the at the end of June early July. The week of July 7th would be excellent, but I have not seen anything scheduled for Internetwork Expert pass June yet. I’m wondering if a boot camp in mid June is ideal if lab is still a month away.

Â

Considering the relative complexity of Border Gateway Protocol(BGP), it’s not surprising that you would consider various design aspects before rushing head-on into implementing it in your network. If nothing else, with a good design and careful planning you could save yourself a few tense troubleshooting sessions.

Use a public autonomous system number

BGP uses autonomous system (AS) numbers to track networks through which the traffic would have to pass to reach the final destination. AS numbers visible in the public Internet have to be globally unique and are allocated by various Internet registries. If you want to offer public Internet services, having a public AS number is mandatory. If you are in hurry and just need BGP to offer other IP-based services (for example, Layer 3 VPN services based on MPLS VPN), you could use a private AS numbers specified in RFC 1930 (AS 64512 through AS 65535), but then you might be faced with challenging migration scenarios if you’d ever want to offer public Internet services.

Full article here

Well I got through half of the first lab this weekend. I ran into a cabling issue Saturday morning that took me a little bit to figure out. The tough part of using Dynamips bridged out to real switches is troubleshooting hardware and software issues. Turned out to be a mix up of the usb ethernet controller on the mac mini and my dynamips internetwork expert file. This mix up was causing R4 and R5 not to be able to talk between Vlan 45. My first attempt at lab one was stopped by this same problem. The issue was the same, but I was so far into the lab that it was hard to find where the issue was. This time I made sure to test out all connectivity after each section and caught this early. It did encourage me that the problem was not something I configured incorrectly a few weeks ago.

The second issue I had was forming the bgp peer session with switch four and BB2. A simple password was needed for the session, neighbor 192.10.1.254 remote-as 254 password CISCO. For some reason though, the peer session would not come up between the two. So I turned on debug and saw the authentication error. I checked the solution guide and I had it exactly right. I decided to console onto BB2 and saw the peer group configuration on there. The password still wouldn’t go through though. I tossed on the bgp peering configuration manually to switch four and everything came up. I’m wondering if I have an old BB2 configuration on my hands. I will have to make sure I get the latest configurations tomorrow before continuing on.

Lesson learned: Always check connectivity after each section, especially in practice labs.

I stopped at that point tonight and will continue on tomorrow.

Another good NAT break down on Internetwork Expert’s site.

Quite many people don’t pay attention to the difference in handling the packets on interfaces configured for NAT inside and outside. Here is an example to demonstrate how NAT “domains” interact with routing. Consider three routers connecte in the following manner:

nat-inside-outside

For this scenario we have no routing configured. Let’s use static NAT to provide connectivity between R1 and R2. R2 would see R1 as a host on local connected segment with the IP address 155.1.23.1 and R1 would see R2 as a host on it’s local segment with the IP address 155.1.13.2. This goal could be achieved with the following configuration:

R3:
!
interface Serial 1/0.301 point-to-point
 ip address 155.1.13.3 255.255.255.0
 ip nat inside
 no ip route-cache
!
interface Serial 1/0.302 multipoint
 ip address 155.1.23.3 255.255.255.0
 frame-relay map ip 155.1.23.2 302
 ip nat outside
 no ip route-cache

!
! Static NAT: translations are effectively bi-directional
!
ip nat inside source static 155.1.13.1 155.1.23.1
ip nat outside source static 155.1.23.2 155.1.13.2

R2:
!
! Add a Frame-Relay mapping for the new IP (representing R1)
! so that R2 would know how to reach the address
! over multipoint FR interface
!
interface Serial 1/0.203 multipoint
 ip address 155.1.23.2 255.255.255.0
 frame-relay map ip 155.1.23.3 203

Full article here

Well I am looking to get back into workbook II lab 1 by next week. If I don’t start soon, it feels like I will never start back up again. I am going to have to break the first few labs up by their topics. I won’t have eight hours to spend on each lab for a while. I would like to get the labs done in two 4 hours sessions on the weekends to start so I have the next five days to read over things that I am not clear on, or having trouble with.

Up until now I have been too concerned with multicast and QOS instead of concentrating on the core items. I need to get those down one hundred percent or else there is no way to pass the lab anyhow. So I decided it is better to get the core down cold and start to worry about the other topics later down the stretch.

Any serious (or at least security-aware) ISP should not blindly accept BGP routes from its customers but at the very minimum do some sanity checks on them. For example, if a multi-homed customer is clumsy enough to advertise BGP routes between service providers, it’s nice if you still stop him from turning into a transit AS. The required filter is conceptually quite simple: all the BGP routes from the customer should contain only his AS number in the AS-path.

The initial non-scalable approach is obvious: accept only the AS paths that have exactly the customer’s AS number in the AS path. For example, if your customer’s AS number is 65001, you could use this filter: ip as-path access-list 100 permit ^65001$.

Full article here

Internetwork Expert has an article up on understanding redistribution, which is always a sticky topic. Configured wrong, or even correctly sometimes can still cause routing loops and routing black holes. It is a very good read.

Abstract: Describe the purpose of redistribution and the issues involved.
Prerequisites: Good understanding of IGP routing protocols (OSPF, EIGRP, RIPv2).

Let’s start straight with a rolling out a group of definitions. Redistribution is a process of passing the routing information from one routing domain to another. The ultimate goal of redistribution is to provide full IP connectivity between different routing domains. Another goal (not always required, though) is to provide redundant connectivity, i.e. backup paths between routing domains. Routing domain is a set of routers running the same routing protocol. Redistribution process is performed by border routers – i.e. routers belonging to more than one routing domain. On the contrary, internal routers belong just to one routing domain. Redistribution may be one-way (from one domain to another but not vice-versa) or two-way (bi-directional). Next, internal routes are the IGP prefixes native to a routing protocol; i.e. they are originated by IGP’s natural method, and their respective subnets belong to the IGP routing domain. External routes are the IGP prefixes injected into IGP routing domain via a border router – they have no corresponding IP subnets in the routing domain. They appear to be “attached” somehow to the border router that has originated them, and detailed information about their reachability is “compressed” and lost during the redistribution. Transit routing domain is the domain used as path to transport packets between two other routing domains. Domain becomes transit when two border routers perform bi-directional redistribution with two other routing domains. Stub routing domain configured not to transit packets (effectively by blocking transit redistribution) between two other domains,Let’s look at a picture to clarify the concepts.

Full article here

When a TCP client attempts to establish a connection to a TCP server it first sends a TCP SYN packet to the server with the destination port as the well known port. This first SYN essentially is a request to open a session. If the server permits the session it will respond with a TCP SYN ACK saying that it acknowledges the request to open the session, and that it also wants to open the session. In this SYN ACK response the server uses the well known port as the source port, and a randomly negotiated destination port. The last step of the three way handshake is the client responding to the server with a TCP ACK, which acknowledges the server’s response and completes the connection establishment.

Now from the perspective of BGP specifically the TCP clients and servers are routers. When the “client” router initiates the BGP session is sends a request to the server with a destination port of 179 and a random source port X. The server then responds with a source port of 179 and a destination port of X. Therefore all client to server traffic uses destination 179, while all server to client traffic uses source 179. We can also verify this from the debug output in IOS.

Full article here

One of the most compelling drivers for MPLS in service provider networks is its support for Virtual Private Networks (VPNs), in which the provider’s customers can connect geographically diverse sites across the provider’s network.

There are three kinds of MPLS-based VPN:

Layer 3 VPNs: With L3 VPNs the service provider participates in the customer’s Layer 3 routing. The customer’s CE router at each of his sites speaks a routing protocol such as BGP or OSPF to the provider’s PE router, and the IP prefixes advertised at each customer site are carried across the provider network. L3 VPNs are attractive to customers who want to leverage the service provider’s technical expertise to insure efficient site-to-site routing.

Layer 2 VPNs: The provider interconnects the customer sites via the Layer 2 technology – usually ATM, Frame Relay, or Ethernet – of the customer’s choosing. The customer implements whatever Layer 3 protocol he wants to run, with no participation by the service provider at that level. L2 VPNs are attractive to customers who want complete control of their own routing; they are attractive to service providers because they can serve up whatever connectivity the customer wants simply by adding the appropriate interface in the PE router.

Virtual Private LAN Service: VPLS makes the service provider’s network look like a single Ethernet switch from the customer’s viewpoint. The attraction of VPLS to customers is that they can make their WAN look just like their local campus- or building-scope networks, using a single technology (Ethernet) that is cheap and well understood. Unlike traditional Metro Ethernet services built around actual Ethernet switches, service providers can connect VPLS customers from regional all the way up to global scales. So a customer with sites in London, Dubai, Bangalore, Hong Kong, Los Angeles, and New York can connect all his sites with what appears to be a single Ethernet switch.

 

Full article here

← Previous PageNext Page →