Networking Concepts

What is Promiscuous Mode

2009-07-21T12:49:22.640+05:30

1) In a network, promiscuous mode allows a network device to intercept and read each network packet that arrives in its entirety. This mode of operation is sometimes given to a network snoop server that captures and saves all packets for analysis (for example, for monitoring network usage).
2) In an Ethernet local area network (LAN), promiscuous mode is a mode of operation in which every data packet transmitted can be received and read by a network adapter. Promiscuous mode must be supported by each network adapter as well as by the input/output driver in the host operating system. Promiscuous mode is often used to monitor network activity.

Promiscuous mode is the opposite of non-promiscuous mode. When a data packet is transmitted in non-promiscuous mode, all the LAN devices "listen to" the data to determine if the network address included in the data packet is theirs. If it isn't, the data packet is passed onto the next LAN device until the device with the correct network address is reached. That device then receives and reads the data.

Multicast TTL-Threshold

2009-02-12T18:14:43.095+05:30

ip multicast ttl-threshold

Usage Guidelines

"Only multicast packets with a TTL value greater than the threshold are forwarded out the interface."

Oh yeah?! I guess it depends on when you look at the TTL. Consider the network:

R1----R2----R3----R4

PIM-DM is enabled everywhere.
R4 has joined 239.0.0.1
R1 is sending pings which have 255 TTL when sent from R1.
R2 receives the PING, decrements the TTL to 254 before sending to R3.

So if we set TTL threshold to 254 on R2's interface to R3, it should block it right? No:

R2(config)#int s1/0
R2(config-if)#ip multicast ttl-threshold 254

R1#ping 239.0.0.1  

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.34.4, 164 ms
R1#

The router will still pass packets that have a TTL equal to the threshold if it was the router that decremented the TTL to reach that value. Here we see 255 will fail:

R2(config)#int s1/0
R2(config-if)#ip multicast ttl-threshold 255

R1#ping 239.0.0.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
.
R1#

WCCP notes

2009-02-12T18:11:58.340+05:30

Troubleshooting OSPF over Frame-Relay

2009-02-12T18:10:27.649+05:30

Frame-relay Compression

2009-02-12T18:08:48.841+05:30

Frame-relay Fragmentation

2009-02-12T18:04:58.053+05:30

Configuring multipoint subinterface so the interface status reflects status of the PVC

2009-02-12T18:04:03.254+05:30

On a physical frame-relay interface, if the opposite end goes down, the local interface will remain up/up. When using multipoint subinterfaces this is not the case. When the remote interface goes down (taking the dlci with it), the local ends puts its interface in a down/down state.R1, R3 and R5 connect via full mesh frame-relay, subnet 190.1.135.0/24R1 dlci 103 maps to R3 dlci 301R1 dlci 105 maps to R5 dlci 501R3 dlci 305 maps to R5 dlci 503Configure all routers on the physical interfaces.Here is the outlook so far from R3:R3#show ip int brief serial 1/0Interface IP-Address OK? Method Status ProtocolSerial1/0 190.1.135.1 YES manual up up R3# Now Let's shut the physical interfaces On R5 and R1:R5(config)#int s0/0R5(config-if)#shutR1(config)#int s0/0R1(config-if)#shutR3 still has its interface up/up:R3#show ip int brief serial 1/0Interface IP-Address OK? Method Status ProtocolSerial1/0 190.1.135.1 YES manual up up If we want R3's interface to go down when R5 and R1 are no longer available we need to use multipoint subinterface. Let's create one on R3 and move the config over:R3(config)#interface Serial1/0R3(config-if)# no ip address 190.1.135.1 255.255.255.0R3(config-if)# no frame-relay map ip 190.1.135.1 301R3(config-if)# no frame-relay map ip 190.1.135.5 305R3(config-if)#int s1/0.3 multipointR3(config-subif)# ip address 190.1.135.1 255.255.255.0R3(config-subif)# frame-relay map ip 190.1.135.1 301 broadcastR3(config-subif)# frame-relay map ip 190.1.135.5 305 broadcastR3(config-subif)# no frame-relay inverse-arpBring up R5 and R1 again and now we have:R3#show ip int brief s1/0.3Interface IP-Address OK? Method Status ProtocolSerial1/0.3 190.1.135.1 YES manual up up Shut down R5 and R3 is stil up but look at the debug frame-relay lmi. The status of PVC 305 is 0x0 which is inactiveR3#show ip int brief s1/0.3Interface IP-Address OK? Method Status ProtocolSerial1/0.3 190.1.135.1 YES manual up up [...]

Back to Back Multilink Frame-Relay

2009-02-12T18:02:50.080+05:30

I had this task on a recent lab. I was surprised I actually got it to work (with some help from the DocCD). Sometimes I skip these boring WAN technology tasks, but sometimes they can be fun if you get them to work :)R6 ==== R9R6 and R6 are connected via two serial links, serial 0/2/0 and serial 0/2/1. The task says to configure these with a /31 on the subnet 172.30.96.0 network. R6 should use DLCI 609 and R9 should use DLCI 906. Now let me say the PG was mistaken in its answer, it didn't have any frame-relay whatsoever - still waiting to hear via email what the deal was. So this is my "tentative" solution, which works great.Here is my R6 config:interface MFR1 ip address 172.30.96.0 255.255.255.254 no keepalive frame-relay map ip 172.30.96.0 609 frame-relay map ip 172.30.96.1 906 broadcast frame-relay interface-dlci 609!interface Serial0/2/0 no ip address encapsulation frame-relay MFR1 clock rate 2000000 no arp frame-relay!interface Serial0/2/1 no ip address encapsulation frame-relay MFR1 clock rate 2000000 no arp frame-relayHere is the R9 config:interface MFR1 ip address 172.30.96.1 255.255.255.254 no keepalive frame-relay map ip 172.30.96.0 609 broadcast frame-relay map ip 172.30.96.1 906 frame-relay interface-dlci 609!interface Serial0/2/0 no ip address encapsulation frame-relay MFR1 no arp frame-relay!interface Serial0/2/1 no ip address encapsulation frame-relay MFR1 no arp frame-relay[...]

ip subnetting

2009-02-10T19:49:30.888+05:30

IP subnetting is a fundamental subject that's critical for any IP network engineer to understand, yet students have traditionally had a difficult time grasping it. Over the years, I've watched students needlessly struggle through school and in practice when dealing with subnetting because it was never explained to them in an easy-to-understand way. I've helped countless individuals learn what subnetting is all about using my own graphical approach and calculator shortcuts, and I've put all that experience into this article. IP addresses and subnets Although IP stands for Internet Protocol, it's a communications protocol used from the smallest private network to the massive global Internet. An IP address is a unique identifier given to a single device on an IP network. The IP address consists of a 32-bit number that ranges from 0 to 4294967295. This means that theoretically, the Internet can contain approximately 4.3 billion unique objects. But to make such a large address block easier to handle, it was chopped up into four 8-bit numbers, or "octets," separated by a period. Instead of 32 binary base-2 digits, which would be too long to read, it's converted to four base-256 digits. Octets are made up of numbers ranging from 0 to 255. The numbers below show how IP addresses increment. 0.0.0.00.0.0.1...increment 252 hosts...0.0.0.2540.0.0.2550.0.1.00.0.1.1...increment 252 hosts...0.0.1.2540.0.1.2550.0.2.00.0.2.1...increment 4+ billion hosts...255.255.255.255 The word subnet is short for sub network--a smaller network within a larger one. The smallest subnet that has no more subdivisions within it is considered a single "broadcast domain," which directly correlates to a single LAN (local area network) segment on an Ethernet switch. The broadcast domain serves an important function because this is where devices on a network communicate directly with each other's MAC addresses, which don't route across multiple subnets, let alone the entire Internet. MAC address communications are limited to a smaller network because they rely on ARP broadcasting to find their way around, and broadcasting can be scaled only so much before the amount of broadcast traffic brings down the entire network with sheer broadcast noise. For this reason, the most common smallest subnet is 8 bits, or precisely a single octet, although it can be smaller or slightly larger. Subnets have a beginning and an ending, and the beginning number is always even and the ending number is always odd. The beginning number is the "Network ID" and the ending number is the "Broadcast ID." You're not allowed to use these numbers because they both have special meaning with special purposes. The Network ID is the official designation for a particular subnet, and the ending number is the broadcast address that every device on a subnet listens to. Anytime you want to refer to a subnet, you point to its Network ID and its subnet mask, which defines its size. Anytime you want to send data to everyone on the subnet (such as a multicast), you send it to the Broadcast ID. Later in this article, I'll show you an easy mathematical and graphical way to determine the Network and Broadcast IDs. The graphical subnet ruler Over the years, as I watched people struggle with the subject of IP subnetting, I wanted a better way to teach the subject. I soon realized that many students in IT lacked the necessary background in mathematics and had a hard time with the concept of binary numbers. To help close this gap, I came up with the graphical method of illustrating subnets shown in Figure A. In this example, we're looking at a range of IP addresses from 10.0.0.0 up to 10.0.32.0. Note that the ending IP of 10.0.32.0 itself is actually the beginning of the next subnet. This network range ends at the number right before it, which is 10[...]

CBAC with APPFW

2009-02-08T16:01:19.288+05:30

I have begun my goal of reading the entire 12.4 Security Configuration Guide. I likely won't read it all because many things are probably unrelated to CCIE R&S, but you never really can tell. Especially since the blueprint has "Other Security Features" on it. This configuration is part of CBAC and so I thought I would test a small scenario.R4----s1/0 R5----R6R4 is the http server and R6 is the client. Here is how I set them up to verify it's working:R4#copy run test.htmlDestination filename [test.html]?Erase flash: before copying? [confirm]Erasing the flash filesystem will remove all files! Continue? [confirm]Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erasedErase of flash: completeVerifying checksum... OK (0x7071)1942 bytes copied in 4.628 secs (420 bytes/sec)R4#R4#dirDirectory of flash:/ 1 -rw- 1942 test.html7864316 bytes total (7862308 bytes free)R4#conf tR4(config)#ip http path flash:R4 is setup, let's test R6 the client:R6#copy http://192.168.45.4/test.html flash:Destination filename [test.html]?Erase flash: before copying? [confirm]Erasing the flash filesystem will remove all files! Continue? [confirm]Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erasedErase of flash: completeLoading http://192.168.45.4/test.html !Verifying checksum... OK (0x7071)1942 bytes copied in 0.688 secs (2823 bytes/sec)R6#Good, so we know that works. Now we can configure R5 as the HTTP Application FW. This does require CBAC as well as some new appfw commands which I have never used. There are MANY more options besides this, so I suggest you read the DocCD for a more in depth explanation. I just wanted to get the gist of it here:ip inspect name APPFW appfw HTTPFWip inspect name APPFW http!appfw policy-name HTTPFW application http strict-http action allow alarm content-length minimum 1945 action reset alarm port-misuse tunneling action resetinterface Serial1/0 description TO R4 ip inspect APPFW outNotice the minimum content length is 1945 byes. This will prevent R6 from copying the file via HTTP (test.html is 1942 bytes as we can see above):6#copy http://192.168.45.4/test.html flash:Destination filename [test.html]?Erase flash: before copying? [confirm]n%Error opening http://192.168.45.4/test.html (I/O error)R6#Jump to R5 and see the message:R5#*Mar 2 05:34:02.708: %APPFW-4-HTTP_CONT_TYPE_SIZE: Sig:11 Content size 1942 out of range - Reset - Content size out-of-bounds from 192.168.56.6:25101 to 192.168.45.4:80If we change the minimum content legth to 1942, everything works as expected:R5(config)#appfw policy-name HTTPFW R5(cfg-appfw-policy)#application http R5(cfg-appfw-policy-http)#content-length minimum 1942 action reset alarmR6#copy http://192.168.45.4/test.html flash:Destination filename [test.html]? %Warning:There is a file already existing with this name Do you want to over write? [confirm]yErase flash: before copying? [confirm]nLoading http://192.168.45.4/test.html !Verifying checksum... OK (0x7071)1942 bytes copied in 0.396 secs (4904 bytes/sec)R6#[...]

BGP aggregation with suppress-map

2009-02-08T15:56:08.419+05:30

BGP aggregation with unsuppress-map option

2009-02-08T15:55:36.236+05:30

BGP no-export community

2009-02-08T15:54:41.974+05:30

BGP - External confedration peers

2009-02-08T15:54:04.849+05:30

It is important to remember when doing confederations that although external confederation peers behave like EBGP peers in several ways, they do NOT modify the next hop without manual configuration.Example:R4 --- [[R1---R3]---[R2]]---R5R1, R2 and R3 are in AS#2 as far as R4 and R5 are concerned. But R1 and R3 share sub-AS 65013, and R2 is in sub-AS 65002. Confederations allow R3 to advertise routes learned from R1 to R2 and vice-versa. Without confederations, this would not happen because routes learned from IBGP neighbors do not get advertise to other IBGP neighbors.Confederations allow this to happen but be careful with the next hop attribute. When R2 passes routes learned from R5 to R3, it will not modify the next hop, but instead leave it pointing to R5. You must use the next-hop-self argument on the neighbor command to allow R3 to install these routes (unless R3 has a route to the R2-R5 network).Suppose the network in questions is 155.1.5.0/24. Here is the output of show ip bgp before the change:R3#show ip bgp 155.1.5.0BGP routing table entry for 155.1.5.0/24, version 5Paths: (1 available, no best path)Flag: 0x208 Not advertised to any peer (65002) 1 155.1.0.5 (inaccessible) from 155.1.23.2 (155.1.23.2) Origin IGP, metric 0, localpref 100, valid, externalAnd after the change:R3#show ip bgp 155.1.5.0BGP routing table entry for 155.1.5.0/24, version 7Paths: (1 available, best #1, table Default-IP-Routing-Table)Flag: 0x208Advertised to non peer-group peers:155.1.13.1(65002) 1 155.1.23.2 from 155.1.23.2 (155.1.23.2) Origin IGP, metric 0, localpref 100, valid, external, best[...]

BGP - Troubleshooting AS Paths with confederations

2009-02-08T15:53:23.920+05:30

I ran into an issue while doing BGP confederations today. In the topology below, I was seeing sub-AS 65013 in the AS PATH on R5 for routes to VLAN4. I found out the problem but I decided to post this so if you ever see this issue, you can tell what it looks like.VLAN4--R4---[[R1---R3]---[R2]]---R5--VLAN5 and 58R4 = AS 3R1,R3 = sub-AS 65013, AS 2R2 = sub-AS 65002, AS 2R5 = AS 1VLAN4 = 204.1.12.0VLAN5 = 155.1.5.0VLAN58 = 155.1.58.0Study the outputs below. Notice that R5 still sees sub-AS 65013 in it's routes to R4. The AS PATH should be: 2 3. What is the error I made?-------------------------------------------------------------------------------In the below output, R4 sees R5's VLAN coming from AS 1 and AS 2. There is no way of telling these come from condeferations.R4#show ip bgpBGP table version is 20, local router ID is 4.4.4.4Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 155.1.5.0/24 155.1.146.1 0 2 1 i*> 155.1.58.0/24 155.1.146.1 0 2 1 i*> 204.12.1.0 0.0.0.0 0 32768 iR4#-------------------------------------------------------------------------------R1 sees both of R5's VLANS as coming from AS 1 and sub-AS 65002. R1 is confederation peer with sub-AS 65002.R1#show ip bgpBGP table version is 8, local router ID is 155.1.146.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*>i155.1.5.0/24 155.1.23.2 0 100 0 (65002) 1 i*>i155.1.58.0/24 155.1.23.2 0 100 0 (65002) 1 i*> 204.12.1.0 155.1.146.4 0 0 3 iR1#-------------------------------------------------------------------------------R3 sees the same thing as R1.R3#show ip bgpBGP table version is 8, local router ID is 155.1.37.3Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 155.1.5.0/24 155.1.23.2 0 100 0 (65002) 1 i*> 155.1.58.0/24 155.1.23.2 0 100 0 (65002) 1 i*>i204.12.1.0 155.1.13.1 0 100 0 3 iR3#-------------------------------------------------------------------------------R2 sees R5's vlan as originating from AS 1. It also sees R4's VLAN as coming from AS 3 and AS 65013 - not sure why there isn't parenthesis around 65013 in this case...R2#sho ip bgpBGP table version is 4, local router ID is 155.1.23.2Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 155.1.5.0/24 155.1.0.5 0 0 1 i*> 155.1.58.0/24 155.1.0.5 0 0 1 i*> 204.12.1.0 155.1.13.1 0 100 0 65013 3 iR2#-------------------------------------------------------------------------------Here are R5 sees R4's VLAN as coming throigh AS 3 65013 and then from AS 2. Why is 65013 appearing?R5#show ip bgpBGP table version is 22, local router ID is 5.5.5.5Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path*> 155.1.5.0/24 0.0.0.0 0 32768 i*> 155.1.58.0/24 0.0.0.0 0 327[...]

BGP - Aggregation with advertise-map

2009-02-08T15:52:36.077+05:30

R1,R2 and R3 connect to R5 via Frame-relayR1-\R2---R5R3-/These 3 spokes are EBGP peers with R5.These routes are advertised into bgp:R1, loopback 150.1.1.1 AS1R2, loopback 150.1.2.2 AS2R3, loopback 150.1.3.3 AS3R5, loopback 150.1.5.5 AS5Here are R3's and R5's BGP table before any aggregation:R5#show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 150.1.1.0/24 155.1.0.1 0 0 1 i*> 150.1.2.0/24 155.1.0.2 0 0 2 i*> 150.1.3.0/24 155.1.0.3 0 0 3 i*> 150.1.5.0/24 0.0.0.0 0 32768 iR3#show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 150.1.1.0/24 155.1.0.1 0 5 1 i*> 150.1.2.0/24 155.1.0.2 0 5 2 i*> 150.1.3.0/24 0.0.0.0 0 32768 i*> 150.1.5.0/24 155.1.0.5 0 0 5 iSuppose R5 wants to advertise a summary-only aggregate to R3:R5(config)#router bgp 5R5(config-router)#aggregate-address 150.1.0.0 255.255.248.0 as-set summary-onlyR3 will deny the route because of the as-set option which forces R5 to include the AS numbers as an unordered set in the AS PATH:R3#show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 150.1.3.0/24 0.0.0.0 0 32768 iR3#debug ip bgp updates00:37:37: BGP(0): 155.1.0.5 rcv UPDATE w/ attr: nexthop 155.1.0.5, origin i, aggregated by 5 150.1.5.5, originator 0.0.0.0, path 5 {1,2,3}, community , extended community00:37:37: BGP(0): 155.1.0.5 rcv UPDATE about 150.1.0.0/21 -- DENIED due to: AS-PATH contains our own AS;R3#We can have R5 remove R3's attributes (AS PATH) in the aggregate by using an advertise-map. This will allow R3 to recieve the aggregate.First we create a prefix-list to match the route:R5(config)#ip prefix-list R3 permit 150.1.3.0/24The we create a route-map, note that we are denying the prefix. This means any matches will NOT have their attributes populated to the aggregate's attributes:R5(config)#route-map DENY3 deny 10R5(config-route-map)#match ip address prefix-list R3R5(config-route-map)#exitR5(config)#route-map DENY3 permit 20R5(config-route-map)#exitFinally, we apply the advertise-map to the aggregate-address command under the bgp process:R5(config)#router bgp 5R5(config-router)#aggregate-address 150.1.0.0 255.255.248.0 as-set summary-only advertise-map DENY3Here are the final results:R5#show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 150.1.0.0/21 0.0.0.0 32768 {1,2} is> 150.1.1.0/24 155.1.0.1 0 0 1 is> 150.1.2.0/24 155.1.0.2 0 0 2 is> 150.1.3.0/24 155.1.0.3 0 0 3 is> 150.1.5.0/24 0.0.0.0 0 32768 iR5#R3#00:46:26: BGP(0): 155.1.0.5 update run completed, afi 0, ran for 4ms, neighbor version 35, start version 38, throttled to 3800:46:26: BGP(0): 155.1.0.5 rcvd UPDATE w/ attr: nexthop 155.1.0.5, origin i, atomic-aggregate, aggregated by 5 150.1.5.5, path 5 {1,2}00:46:26: BGP(0): 155.1.0.5 rcvd 150.1.0.0/2100:46:26: BGP(0): Revise route installing 150.1.0.0/21 -> 155.1.0.5 to main IP tableR3#R3#show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 150.1.0.0/21 155.1.0.5 0 5 {1,2} i*> 150.1.3.0/24 0.0.0.0 0 32768 iR3#Notice that the aggregate only has AS1 and AS2 in the AS PATH. This allows R3 to install the [...]

BGP - Conditional Advertisement with non-exist-map

2009-02-08T15:51:57.450+05:30

It took me awhile to get this going for some reason but here is the doc that helped me out:Configuring and Verifying the BGP Conditional Advertisement FeatureHere's my example[R1]---[R4]---[R5]Each router is in its own AS.R1 is advertising 10.1.0.0/16 to R4.if this route should fail, then R4 should advertise 4.4.4.0/24 to R5.If 10.1.0.0/16 appears in R4's BGP table, then it should stop advertising 4.4.4.0/24.R4 is where the action is so let's have a look:!interface Loopback0 ip address 4.4.4.4 255.255.255.0!router bgp 4 no synchronization bgp log-neighbor-changes network 4.4.4.0 mask 255.255.255.0 neighbor 155.1.45.5 remote-as 5 neighbor 155.1.45.5 advertise-map ADV non-exist-map NON neighbor 155.1.146.1 remote-as 1 no auto-summary!access-list 10 permit 10.1.0.0 0.0.255.255access-list 40 permit 4.4.4.0 0.0.0.255!route-map NON permit 10 match ip address 10!route-map ADV permit 10 match ip address 4010.1.0.0 is actually the loopback network on R1 so we can test easy by shutting/no shutting the interface. Right now it is up. Let's check the BGP tables on R4 and R5:R4#show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 4.4.4.0/24 0.0.0.0 0 32768 i*> 10.1.0.0/16 155.1.146.1 0 0 1 iR5#show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 10.1.0.0/16 155.1.45.4 0 4 1 iNow let's shut the interface on R1:R1(config)#int lo 1R1(config-if)#shutNow check R4 and R5 again:R4#show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 4.4.4.0/24 0.0.0.0 0 32768 iR5#debug ip bgp updatesBGP updates debugging is on for address family: IPv4 Unicast*Mar 1 01:59:35.787: BGP(0): 155.1.45.4 rcvd UPDATE w/ attr: nexthop 155.1.45.4, origin i, metric 0, path 4*Mar 1 01:59:35.791: BGP(0): 155.1.45.4 rcvd 4.4.4.0/24*Mar 1 01:59:35.799: BGP(0): Revise route installing 1 of 1 routes for 4.4.4.0/24 -> 155.1.45.4(main) to main IP tableR5#show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 4.4.4.0/24 155.1.45.4 0 0 4 i[...]

BGP - expanded community-lists

2009-02-08T15:51:12.849+05:30

BGP expanded community-lists are more flexible than their standard counterparts because they can match on regexp instead of just a community string. Here you can see the differences:R4(config)#ip community-list standard STANDARD permit ? community number aa:nn community number internet Internet (well-known community) local-AS Do not send outside local AS (well-known community) no-advertise Do not advertise to any peer (well-known community) no-export Do not export to next AS (well-known community) R4(config)#ip community-list expanded EXPANDED permit ? LINE An ordered list as a regular-expressionNow for a little lab. R1 and R2 are both going to EBGP peer with R4. R4 will then EBGP peer with R3. R1 and R2 will each send routes with different community strings to R4, along with routes without a community. We will use an expanded list to match certain community values. Hopefully, we can get it done with one permit statement.R1 has 4 loopback networks:1.0.0.0/241.0.1.0/241.0.2.0/241.0.3.0/24R2 has 4 loopback networks:2.0.0.0/242.0.1.0/242.0.2.0/242.0.3.0/24R1 is sending community 100 with its first two loopbacksR2 is sending community 200 with its first two loopbacksThe other loopbacks do not have a community attached.Here is how we do it on R1, R2 is similar:R1(config)#ip prefix-list LOOP1 permit 1.0.0.0/24R1(config)#ip prefix-list LOOP1 permit 1.0.1.0/24R1(config)#route-map setcomR1(config-route-map)#match ip address prefix LOOP1R1(config-route-map)#set commu 100R1(config-route-map)#exitR1(config)#route-map setcom perm 20R1(config-route-map)#exitR1(config)#router bgp 65000R1(config-router)#neighbor 172.12.14.4 send-communityR1(config-router)#neighbor 172.12.14.4 route-map setcom outVerify on R4 (this shows R4 is receiving all loopbacks)R4#sho ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 1.0.0.0/24 172.12.14.1 0 0 65000 i*> 1.0.1.0/24 172.12.14.1 0 0 65000 i*> 1.0.2.0/24 172.12.14.1 0 0 65000 i*> 1.0.3.0/24 172.12.14.1 0 0 65000 i*> 2.0.0.0/24 172.12.24.2 0 0 65000 i*> 2.0.1.0/24 172.12.24.2 0 0 65000 i*> 2.0.2.0/24 172.12.24.2 0 0 65000 i*> 2.0.3.0/24 172.12.24.2 0 0 65000 iHere are the loopbacks with community attributes:R4#show ip bgp community 100 | begin Net Network Next Hop Metric LocPrf Weight Path* 1.0.0.0/24 172.12.14.1 0 0 65000 i* 1.0.1.0/24 172.12.14.1 0 0 65000 iR4#show ip bgp community 200 | begin Net Network Next Hop Metric LocPrf Weight Path* 2.0.0.0/24 172.12.24.2 0 0 65000 i* 2.0.1.0/24 172.12.24.2 0 0 65000 iHere is R3:R3#show ip bgp Network Next Hop Metric LocPrf Weight Path*> 1.0.0.0/24 172.12.34.4 0 400 65000 i*> 1.0.1.0/24 172.12.34.4 0 400 65000 i*> 1.0.2.0/24 172.12.34.4 0 400 65000 i*> 1.0.3.0/24 172.12.34.4 0 400 65000 i*> 2.0.0.0/24 172.12.34.4 0 400 65000 i*> 2.0.1.0/24 172.12.34.4 0 400 65000 i*> 2.0.2.0/24 172.12.34.4 0 400 65000 i*> 2.[...]

BGP - prefix-based outbound route filtering

2009-02-08T15:49:56.785+05:30

Prefix-based outbound route filtering is used so a local router can tell it's peer what routes it should send/filter. This prevents unnecessary resources from being used. There is no sense in a router sending a bunch of route updates, if they are only going to get filtered anyway.In this example we have EBGP peers R4 and R3:[R4]---[R3]R3 is receiving a bunch of routes from R4:R3#show ip bgp Network Next Hop Metric LocPrf Weight Path *> 1.0.0.0/24 172.12.34.4 0 400 65000 i*> 1.0.1.0/24 172.12.34.4 0 400 65000 i*> 1.0.2.0/24 172.12.34.4 0 400 65000 i*> 1.0.3.0/24 172.12.34.4 0 400 65000 i *> 2.0.0.0/24 172.12.34.4 0 400 65000 i *> 2.0.1.0/24 172.12.34.4 0 400 65000 i *> 2.0.2.0/24 172.12.34.4 0 400 65000 i *> 2.0.3.0/24 172.12.34.4 0 400 65000 i *> 3.3.3.0/24 0.0.0.0 0 32768 i *> 4.0.0.0/24 172.12.34.4 0 0 400 i *> 4.0.1.0/24 172.12.34.4 0 0 400 i *> 4.0.2.0/24 172.12.34.4 0 0 400 i *> 4.0.3.0/24 172.12.34.4 0 0 400 iR3 only wants to receive 3 routes:1.0.0.0/242.0.0.0/244.0.0.0/24R3 can create a prefix-list allowing these 3 routes only and advertise this to R4. R4 will use this list as a outbound filter. Let's configure it. First you need enable the advertisement of the orf capability. R3 is the one sending the prefix-list so use the send keyword. R4 is receiving the prefix-list.R3(config)#router bgp 65003R3(config-router)#neighbor 172.12.34.4 capability orf prefix-list send R4(config)#router bgp 400R4(config-router)#neighbor 172.12.34.3 capability orf prefix-list receiveNow configure the prefix-list and apply it to the neighbor:R3(config)#ip prefix-list ZERO seq 5 permit 1.0.0.0/24 R3(config)#ip prefix-list ZERO seq 10 permit 2.0.0.0/24 R3(config)#ip prefix-list ZERO seq 15 permit 4.0.0.0/24R3(config)#router bgp 65003 R3(config-router)#neighbor 172.12.34.4 prefix-list ZERO inR3#clear ip bgp * soft in prefix-filterHere is the final result:R3#show ip bgp Network Next Hop Metric LocPrf Weight Path *> 1.0.0.0/24 172.12.34.4 0 400 65000 i *> 2.0.0.0/24 172.12.34.4 0 400 65000 i *> 3.3.3.0/24 0.0.0.0 0 32768 i *> 4.0.0.0/24 172.12.34.4 0 0 400 iHere are some captures I took in dynamips. The first shows the advertisement of the orf capability. The second shows the actually prefix-list R3 is sending. Wireshark shows this as "route-refresh" message. Pretty cool, eh?Restrictions:I used the bgp upgrade-cli command to configure these neighbors in AF mode.Also, prefix-lists must be used, not ACL or distribute lists[...]

BGP - changing cluster-id

2009-02-08T15:48:51.293+05:30

The network:[R3]---[R5]---[R4]---[EXTERNAL AS]R3 is IBGP peer with R5R5 is IBGP peer with R4R5 is the route reflectorHere is the bgp entry for a route learned initially from R4:R3#show ip bgp 6.0.0.0BGP routing table entry for 6.0.0.0/24, version 5Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 65000 4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 4.4.4.4, Cluster list: 5.5.5.5Changing the cluster-id:R5(config)#router bgp 345R5(config-router)#bgp cluster-id ? Route-Reflector Cluster-id as 32 bit quantity A.B.C.D Route-Reflector Cluster-id in IP address formatR5(config-router)#bgp cluster-id 5Here's how the change looks on R3:R3#show ip bgp 6.0.0.0BGP routing table entry for 6.0.0.0/24, version 9Paths: (1 available, best #1, table Default-IP-Routing-Table)Flag: 0x800 Not advertised to any peer 65000 4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 4.4.4.4, Cluster list: 0.0.0.5[...]

BGP - set clauses are ignored on reflected routes

2009-02-08T15:48:12.392+05:30

Network:R4,R5,R6 have serial interfaces connected to Frame cloud 172.14.45.0/24R3,R4,R5 have LAN interfaces connected to 172.12.34.0/24R6 has EBGP peering with R5 and R4, however R5 has R6 neighbor shutdown for now.R4 is connected to R5 via IBGP.R5 then connects to R3 via IBGP.R5 has R3 configured as a route-reflector client.R5 reflects routes learned from R4 to R3.R5 has the following config:router bgp 345 bgp cluster-id 5 neighbor 3.3.3.3 remote-as 345 neighbor 3.3.3.3 update-source Loopback0 ! address-family ipv4 neighbor 3.3.3.3 activate neighbor 3.3.3.3 send-community neighbor 3.3.3.3 route-reflector-client neighbor 3.3.3.3 route-map SET out!ip prefix-list SIX seq 5 permit 6.0.0.0/24!route-map LOOPBACK permit 10 match ip address 5!route-map SET permit 10 match ip address prefix-list SIX set community 500!route-map SET permit 20!The community does not show up on R3:R3#show ip bgp 6.0.0.0BGP routing table entry for 6.0.0.0/24, version 9Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 65000 4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 4.4.4.4, Cluster list: 0.0.0.5Now let's peer R5 directly with R6 and see what happens:R5(config)#router bgp 345R5(config-router)#neighbor 4.4.4.4 shutdownR5(config-router)#no neighbor 172.14.45.6 shutdownImmediately the community shows up on R3:R3#show ip bgp 6.0.0.0BGP routing table entry for 6.0.0.0/24, version 13Paths: (1 available, no best path)Flag: 0x820 Not advertised to any peer 65000 172.14.45.6 (inaccessible) from 5.5.5.5 (5.5.5.5) Origin IGP, metric 200, localpref 100, valid, internal Community: 500I got this info while browsing the DocCD:Configuring a Route Reflector"The use of set clauses in outbound route maps can modify attributes and possibly create routing loops. To avoid this behavior, set clauses of outbound route maps are ignored for routes reflected to iBGP peers."[...]

BGP - deterministic-med and always-compare-med

2009-02-08T15:46:51.818+05:30

How the bgp deterministic-med Command Differs from the bgp always-compare-med CommandIn order to get the various routes to look right in the bgp table, it took some work. Here is a picture that helps explain it. I'm not gonna put addressing on it. If you want configs, let me know.Our focus is on R1, it has 3 bgp entries to 3.3.3.0:R1#show ip bgp 3.3.3.0BGP routing table entry for 3.3.3.0/24, version 24Paths: (3 available, best #3, table Default-IP-Routing-Table)Advertised to non peer-group peers:172.12.12.2 172.12.14.4400172.12.12.2 from 172.12.12.2 (2.2.2.2) Origin IGP, metric 100, localpref 100, valid, internal400172.12.14.4 from 172.12.14.4 (4.0.3.4) Origin IGP, metric 150, localpref 100, valid, external65003172.12.13.3 from 172.12.13.3 (3.3.3.3) Origin IGP, metric 200, localpref 100, valid, external, bestR1#Tiebreaker:1. entry1 and entry2 are compared, entry2 is picked because external > internal2. entry2 and entry3 are compared, entry 3 picked because RID 3.3.3.3Now let's configre always-compare-med:R1(config)#router bgp 65000R1(config-router)#bgp always-compare-medThis command should allow entry1 to be picked over entry2 (lower MED), then entry1 will be preferred over entry3 (also lower MED):R1#show ip bgp 3.3.3.0BGP routing table entry for 3.3.3.0/24, version 41Paths: (3 available, best #1, table Default-IP-Routing-Table)Flag: 0x820 Advertised to non peer-group peers: 172.12.13.3 172.12.14.4 400 172.12.12.2 from 172.12.12.2 (2.2.2.2) Origin IGP, metric 100, localpref 100, valid, internal, best 400 172.12.14.4 from 172.12.14.4 (4.0.3.4) Origin IGP, metric 150, localpref 100, valid, external 65003 172.12.13.3 from 172.12.13.3 (3.3.3.3) Origin IGP, metric 200, localpref 100, valid, externalIt works!Notice that entries are compared in pairs. To get the pairs reordered you may have shut peers down and enable them accordingly. Example: I wanted the peers to appear in this order 4.0.3.4, 3.3.3.3, and 2.2.2.2. So I brought them up in reverse order: 2.2.2.2, 3.3.3.3, and finally 4.0.3.4. I just did a shut/no shut on the interface. Now I have:R1#show ip bgp 3.3.3.0BGP routing table entry for 3.3.3.0/24, version 47Paths: (3 available, best #3, table Default-IP-Routing-Table) Advertised to non peer-group peers: 172.12.13.3 172.12.14.4 400 172.12.14.4 from 172.12.14.4 (4.0.3.4) Origin IGP, metric 150, localpref 100, valid, external 65003 172.12.13.3 from 172.12.13.3 (3.3.3.3) Origin IGP, metric 200, localpref 100, valid, external 400 172.12.12.2 from 172.12.12.2 (2.2.2.2) Origin IGP, metric 100, localpref 100, valid, internal, bestNotice the best route is still from 2.2.2.2 because always-compare-med is enabled. Let's try bgp deterministic-med, without always compare-med. First reset bgp, then continue.R1(config)#router bgp 65000R1(config-router)#no bgp always-compare-medR1(config-router)#bgp deterministic-medIn this case entry2 should be compared to entry3 with entry 2 winning based on lower MED (they are in the same AS so MED is compared). Then entry2 is compared to entry1, with entry1 winning because external bgp is preferred over internal. MED is not compared between these entries.R1#show ip bgp 3.3.3.0BGP routing table entry for 3.3.3.0/24, version 11Paths: (3 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 172.12.12.2 172.12.14.4 65003 172.12.13.3 from 172.12.13.3 (3.3.3.3) Origin IGP, metric 200, localpref 100, valid, external, best 400 172.12.12[...]

BGP - maximum-prefix command

2009-02-08T15:45:38.101+05:30

The network: [R5]---[R6]R5 connects to R6 via EBGPR5 is 172.14.45.5R6 is 172.45.45.6R6 is advertising 10 networks to R5:R5#show ip bgp | inc 45\.6*> 6.0.0.0/24 172.14.45.6 0 0 65000 i*> 6.0.1.0/24 172.14.45.6 0 0 65000 i*> 6.0.2.0/24 172.14.45.6 0 0 65000 i*> 6.0.3.0/24 172.14.45.6 0 0 65000 i*> 6.0.4.0/24 172.14.45.6 0 0 65000 i*> 6.0.5.0/24 172.14.45.6 0 0 65000 i*> 6.0.6.0/24 172.14.45.6 0 0 65000 i*> 6.0.7.0/24 172.14.45.6 0 0 65000 i*> 6.0.8.0/24 172.14.45.6 0 0 65000 i*> 6.0.9.0/24 172.14.45.6 0 0 65000 iI am going to play with a few options of the maximum-prefix command and see the effect. First let's configure a maximum of 8 routes:R5(config)#router bgp 65005R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8R5(config-router)#.Jul 14 20:45:41.467: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down Maximum-Prefix restart timeout.Jul 14 20:46:10.519: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up.Jul 14 20:46:11.919: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8.Jul 14 20:46:11.927: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8.Jul 14 20:46:11.931: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent.Jul 14 20:46:11.931: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytesR5(config-router)# FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0058 0200 0000 1940 0101 0040 0204 0201 FDE8 4003 04AC 0E2D 0680 0404 0000 0000 1806 0009 1806 0008 1806 0007 1806 0006 1806 0005 1806 0004 1806 0003 1806 0002 1806 0001 1806 0000Notice that the nighbor tried to come up after I configured the max. It never tried to come up again after going down the second time. Now the neighbor has the following output (much of the output is omitted):R5#show clock.20:50:26.655 UTC Mon Jul 14 2008R5#R5#show ip bgp neighbor 172.14.45.6...Peer had exceeded the max. no. of prefixes configured.Maximum prefixes allowed 8Threshold for warning message 75%Reduce the no. of prefix and clear ip bgp 172.14.45.6 to restore peeringWe can also configure the router to try and establush the connection again after the max limit is reached and the connection is brought down:R5(config)#router bgp 65005R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 restart 1Here is a sample of the output, the connection tries to re-establish but then drops because the max-prefix limit is reached:R5#.Jul 14 20:53:16.779: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up.Jul 14 20:53:16.811: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8.Jul 14 20:53:16.819: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8.Jul 14 20:53:16.823: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent.Jul 14 20:53:16.827: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes.Jul 14 20:54:15.999: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up.Jul 14 20:54:16.011: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8.Jul 14 20:54:16.015: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8.Jul 14 20:54:16.023: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down [...]

BGP - local-as option

2009-02-08T15:44:12.181+05:30

BGP local-as option allows a router to appear as if it is in another AS. Suppose we have a frame-relay cloud with 3 routers all EBGP peers with each other:R6: 172.14.45.6 (AS 65000)R5: 172.14.45.5 (AS 65005)R4: 172.14.45.4 (AS 345)We can configure R6 to use the local-as option to appear to be from AS 65006 to R5, but remain in AS65000 for R4. Here's how:R6(config-router)#router bgp 65000R6(config-router)#neighbor 172.14.45.5 local-as 65006On R5:R5(config)#router bgp 65005R5(config-router)#neighbor 172.14.45.6 remote-as 65006Let's take a look at the neighbor summary:R5# show ip bgp summary | be NeNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd172.14.45.6 4 65006 220 221 244 0 0 00:03:39 9R4#show ip bgp summary | be Ne172.14.45.6 4 65000 176 146 69 0 0 00:00:08 11Notice the different AS numbers. Also notice the AS path from R5's view:R5# show ip bgp | inc 172.14.45.6*> 6.0.3.0/24 172.14.45.6 0 0 65006 65000 i*> 6.0.4.0/24 172.14.45.6 0 0 65006 65000 i*> 6.0.5.0/24 172.14.45.6 0 0 65006 65000 iAnd the AS path from R6's view also includes the local-AS number:R6#show ip bgp | be Ne Network Next Hop Metric LocPrf Weight Path*> 2.2.2.2/32 172.14.45.5 0 65006 65005 65002 i*> 5.5.5.5/32 172.14.45.5 0 0 65006 65005 iThe routes appear to magically pass through 65006. We can prevent R6 from prepending the local-as number on routes received from R6 with the no-prepend optionR6(config)#router bgp 65000R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend65006 is no longer in the AS Path:R6#show ip bgp | be Ne Network Next Hop Metric LocPrf Weight Path*> 2.2.2.2/32 172.14.45.5 0 65005 65002 i*> 5.5.5.5/32 172.14.45.5 0 0 65005 iWith the replace-AS we can prevent R5's real BGP AS number from appearing in the AS path on routes from R6 to R5:R6(config)#router bgp 65000R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend replace-asR5# show ip bgp | be Ne Network Next Hop Metric LocPrf Weight Path*> 6.0.3.0/24 172.14.45.6 0 0 65006 i*> 6.0.4.0/24 172.14.45.6 0 0 65006 i*> 6.0.5.0/24 172.14.45.6 0 0 65006 iLastly, we can configure R6 to accept connections to either AS 65000 or AS 65006 with the dual-as option:R6(config)#router bgp 65000R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend replace-as dual-asR5#show ip bgp summaryNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd172.14.45.6 4 65006 268 284 343 0 0 00:00:08 9R5#conf tEnter configuration commands, one per line. End with CNTL/Z.R5(config)#router bgp 65005R5(config-router)#neighbor 172.14.45.6 remote-as 65000R5(config-router)#.Jul 14 21:34:34.273: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down Remote AS changedR5(config-router)#.Jul 14 21:34:36.505: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 UpR5(config-router)#R5(config-router)#^ZR5#show ip bgp summaryNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd172.14.45.6 4 65000 270 286 0 0 0 00:00:09 0[...]

BGP - TTL security

2009-02-08T15:43:26.660+05:30

Suppose R5 and R6 are EBGP peers. Each send BGP packets with TTL of 1 to each other. They process any BGP packet with a TTL value of 1 or higher. So if an attacker wants to cause mayhem he can send tons of BGP packets to an edge router in a type of DoS attack and these packets will be processed no matter how far away the attacker is. With BGP TTL Security we can configure the router to expect to receive packets with higher TTL values. That way, an attacker more than the configured number of hops away, will never be able to DoS the router.Example:On R6 we configure:R6(config)#router bgp 65000R6(config-router)#neighbor 172.14.45.5 ttl-security hops 5After 3 minutes (BGP default time) without a keepalive, R6 drops the neighbor:Mar 1 03:16:55.467: %BGP-5-ADJCHANGE: neighbor 172.14.45.5 Down BGP Notification sentMar 1 03:16:55.467: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.5 4/0 (hold time expired) 0 bytesThe reason this happens is because after the TTL security command is configured, R6 will silently drop any packet with a TTL lower of 250 or lower. If it receives a packet with TTL 250, I think it will drop it according to my testing. How can we make R5 send packets with a TTL of 251? We can use TTL-security on that router to or use ebgp-multihop.In this case I use ebgp-multihop:R5(config)#router bgp 65005R5(config-router)#neighbor 172.14.45.6 ebgp-multihop 251.Jul 14 23:01:46.740: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 UpIn this case we use TTL security on R5:R5(config)#router bgp 65005R5(config-router)#no neighbor 172.14.45.6 ebgp-multihop 251R5(config-router)#neighbor 172.14.45.6 ttl-security hops 5After clearing the session:.Jul 14 23:05:15.131: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 UpYou can verify like this:R6#show ip bgp neighbors 172.14.45.5 | inc TTL(output omitted)External BGP neighbor may be up to 5 hops away.Connection is ECN Disabled, Mininum incoming TTL 250, Outgoing TTL 255I don't know why ebgp-multihop didn't work with 250. Perhaps the router decrements it before processing and then sees 249 as the TTL. [...]

Comments (0) - Read and Add your own Comments