I am working through Narbiks BGP workbook again.
Archive for April, 2009
I am working through Narbiks BGP workbook again.
Posted by Peter Kurdziel on April 30, 2009
Posted in Routing & Switching Lab | Leave a Comment »
E1 and E2 routes in OSPF
Posted by Peter Kurdziel on April 24, 2009
Occasionally I stumble across information on the Internet that’s slightly misleading since it doesn’t tell the whole story. For example, this post about OSPF external routes should tell you more about the OSPF route selection process. Just in case you haven’t been deeply involved in it yet, here are the rules:
- Intra-area routes are preferred over inter-area or external routes regardless of their cost; see Section 16.2 paragraph (6) of the OSPF RFC.
- Inter-area routes are preferred over external routes; see Section 16.2 paragraph (5) of the OSPF RFC.
- E1 routes are preferred over E2 routes; see Section 16.4 paragraph (6) of the OSPF RFC.
- When comparing E1 routes, the route metric is the external cost added to the internal cost; see Section 16.4 paragraph (6.d) of the OSPF RFC.
- The internal cost of an E1/E2 route is the cost between the current router and the forwarding address specified in the Type-5 LSA (or originating ASBR if the forwarding address is set to 0.0.0.0); see Section 16.4 paragraph (3) of the OSPF RFC.
- When comparing E2 routes, only the external costs are compared; see Section 16.4 paragraph (6.b) of the OSPF RFC.
- If multiple E2 routes have the same external cost, the internal cost (as above) is compared; see Section 16.4 paragraph (6.d) of the OSPF RFC.
POSTED BY IVAN PEPELNJAK ON THURSDAY, JANUARY 17, 2008
source:http://blog.ioshints.info/2008/01/e1-and-e2-routes-in-ospf.html
Posted in OSPF | Leave a Comment »
IPV6 stateless autoconfiguration
Posted by Peter Kurdziel on April 13, 2009
The following is a summary of the steps a device takes when using stateless autoconfiguration:
1. Link-Local Address Generation: The device generates a link-local address. Recall that this is one of the two types of local-use IPv6 addresses. Link-local addresses have “1111 1110 10” for the first ten bits. The generated address uses those ten bits followed by 54 zeroes and then the 64 bit interface identifier. Typically this will be derived from the data link layer (MAC) address as explained in the topic on interface identifiers, or it may be a “token” generated in some other manner.
2. Link-Local Address Uniqueness Test: The node tests to ensure that the address it generated isn’t for some reason already in use on the local network. (This is very unlikely to be an issue if the link-local address came from a MAC address but more likely if it was based on a generated token.) It sends a Neighbor Solicitation message using the Neighbor Discovery (ND) protocol. It then listens for a Neighbor Advertisement in response that indicates that another device is already using its link-local address; if so, either a new address must be generated, or autoconfiguration fails and another method must be employed.
3. Link-Local Address Assignment: Assuming the uniqueness test passes, the device assigns the link-local address to its IP interface. This address can be used for communication on the local network, but not on the wider Internet (since link-local addresses are not routed).
4. Router Contact: The node next attempts to contact a local router for more information on continuing the configuration. This is done either by listening for Router Advertisement messages sent periodically by routers, or by sending a specific Router Solicitation to ask a router for information on what to do next. This process is described in the section on the IPv6 Neighbor Discovery protocol.
5. Router Direction: The router provides direction to the node on how to proceed with the autoconfiguration. It may tell the node that on this network “stateful” autoconfiguration is in use, and tell it the address of a DHCP server to use. Alternately, it will tell the host how to determine its global Internet address.
6. Global Address Configuration: Assuming that stateless autoconfiguration is in use on the network, the host will configure itself with its globally-unique Internet address. This address is generally formed from a network prefix provided to the host by the router, combined with the device’s identifier as generated in the first step.
Posted in IPV6, Real World | Leave a Comment »
Notes from a mock lab I took this weekend
Posted by Peter Kurdziel on April 13, 2009
1. PPPoFR =
interface Virtual-Template1 ip address 1.1.1.1 255.255.255.0 ppp chap hostname ROUTER1 ppp chap password 0 CISCOinterface Serial0/0 encapsulation frame-relay frame-relay interface-dlci 201 ppp Virtual-Template1R1#show ip interface brief | include 1.1.1.1 Virtual-Access1 1.1.1.1 YES TFTP up up Virtual-Template1 1.1.1.1 YES manual down downUnderstanding and Configuring PPP CHAP Authentication
http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a00800b4131.shtmlTroubleshooting PPP (CHAP or PAP) Authentication
http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a00800b4130.shtml 2. One interface has no keepalive and the other does not. The opposite interface would not come up until I entered "no keepalive" on it. 3. One of my RIP routers was not getting any RIP routes from it's neighbor because I fat fingered ver 2 and it was not in the config. Once I added ver 2 under RIP everything was fine. 4. RIP: ignored v2 update from bad source = no validate update-source5.
queue-list 1 protocol ip 3 tcp telnet queue-list 1 protocol ip 5 tcp smtp queue-list 1 default 4 queue-list 1 queue 3 byte-count 3000 limit 200 queue-list 1 queue 4 byte-count 15000 limit 40
Posted in Routing & Switching Lab | Leave a Comment »
site to site vpn
Posted by Peter Kurdziel on April 9, 2009
R1
crypto isakmp policy 10
encr 3des
authentication pre-share
crypto isakmp key VPNKEY address 192.168.2.2
crypto isakmp invalid-spi-recovery
!
!
crypto ipsec transform-set TS_MD5_TUNNEL esp-3des esp-md5-hmac
crypto ipsec transform-set TS_E3S_TUNNEL esp-3des esp-sha-hmac
!
crypto map CM_VPN 10 ipsec-isakmp
description to R2
set peer 192.168.2.2
set transform-set TS_E3S_TUNNEL
match address VPNACL
qos pre-classify
!
!
!
!
interface Loopback1
ip address 100.1.1.1 255.255.255.0
!
interface Tunnel0
ip address 172.16.1.2 255.255.255.0
tunnel source Loopback1
tunnel destination 10.1.1.1
!
interface Tunnel99
description vpn tunnel to r2
ip unnumbered Loopback1
tunnel source 192.168.10.2
tunnel destination 192.168.2.2
crypto map CM_VPN
!
!
interface Serial1/0
ip address 192.168.10.2 255.255.255.0
serial restart-delay 0
crypto map CM_VPN
!
router eigrp 10
network 100.1.1.1 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.10.0
no auto-summary
!
!
ip access-list extended VPNACL
permit gre host 192.168.10.2 host 192.168.2.2
!
==================================
r2
crypto isakmp policy 10
encr 3des
authentication pre-share
crypto isakmp key VPNKEY address 192.168.10.2
crypto isakmp invalid-spi-recovery
!
!
crypto ipsec transform-set TS_MD5_TUNNEL esp-3des esp-md5-hmac
crypto ipsec transform-set TS_E3S_TUNNEL esp-3des esp-sha-hmac
!
crypto map CM_VPN 10 ipsec-isakmp
description to R1
set peer 192.168.10.2
set transform-set TS_E3S_TUNNEL
match address VPNACL
qos pre-classify
!
!
interface Loopback1
ip address 200.1.1.1 255.255.255.0
!
interface Tunnel0
ip address 172.16.1.3 255.255.255.0
tunnel source Loopback1
tunnel destination 10.1.1.1
!
interface Tunnel99
description vpn to r1
ip unnumbered Loopback1
tunnel source 192.168.2.2
tunnel destination 192.168.10.2
crypto map CM_VPN
!
interface Serial1/0
ip address 192.168.2.2 255.255.255.0
serial restart-delay 0
crypto map CM_VPN
!
router eigrp 10
network 172.16.1.3 0.0.0.0
network 192.168.2.0
network 200.1.1.1 0.0.0.0
no auto-summary
!
!
ip access-list extended VPNACL
permit gre host 192.168.2.2 host 192.168.10.2
Posted in Real World, Security | Leave a Comment »
BGP: regular expression
Posted by Peter Kurdziel on April 7, 2009
filter networks that originated in AS 300
ip as-path access-list 1 deny _300$
ip as-path access-list 1 permit .*
!
router bgp 100
neighbor 10.1.12.2 filter-list 1 in
filter networks that traveresed through AS 300
ip as-path access-list 1 deny _300_
ip as-path access-list 1 permit .*
!
router bgp 100
neighbor 10.1.12.2 filter-list 1 in
filter networks that originated in AS 300
ip as-path access-list 1 deny ^$
ip as-path access-list 1 permit .*
neighbor 10.1.23.2 filter-list 1 out
filter networks from neigboring AS 200
ip as-path access-list 1 deny _200_300$
ip as-path access-list 1 permit .*
!
ip as-path access-list 1 deny ^200$
ip as-path access-list 1 per .*
filter all prefixes from my directly connected neighbors
ip as-path acc 1 deny ^[0-9]+$
ip as-path acc 1 per .*
filter all prefixes that originated in AS 300 and traversed through AS 200
ip as-path access-list 1 deny _200_300$
ip as-path access-list 1 permit .*
Posted in BGP, Routing & Switching Lab | Leave a Comment »
BGP: outbound route filtering
Posted by Peter Kurdziel on April 7, 2009
outbound route filtering
You configure a prefix list on R1 but you want R2 and R3 to actually perform the filtering.
So R1 sends and R2 & R3 receive.
r1
ip prefix …….
nei x.x.x.x prefix ??? in
neighbor x.x.x.x capability orf prefix-list send
r2/r3
neighbor x.x.x.x capability orf prefix-list receive
Posted in BGP, Routing & Switching Lab | Leave a Comment »
BGP: Filtering networks
Posted by Peter Kurdziel on April 7, 2009
filtering networks
Don’t forget the permit any for acl’s or prefix-lists!
1.
acl 1 deny x.x.x.x y.y.y.y
acl 1 per any
2.
ip prefix 1 deny x.x.x.x/x
ip prefix 1 perm 0.0.0.0/0 le 32
3.
acl 2 deny x.x.x.x y.y.y.y
acl 2 per any
route-map BLOCK2 per 10
matc ip 2
4.
acl 2 per x.x.x.x y.y.y.y
route-map BLOCK2 deny 10
matc ip 2
route-map BLOCK2 per 20
then apply to the neighbors
Posted in BGP, Routing & Switching Lab | Leave a Comment »
Notes from Narbik’s BGP labs 6- 10
Posted by Peter Kurdziel on April 6, 2009
shortest as-path is preferred. You can manipulate the
path by prepending as’s making the as-path longer and
therefore less preferred.
*>i11.0.0.0 10.1.12.1 0 100
0 100 i
* 10.1.14.1 0
0 100 100 100 100 100 i
weight
apply in – affects outbound routes
local- preff
apply in – affects outbound routes – higher is better -
this is used to prefer and exit point from the local AS.
as-path
apply out – affects inbound routes – shortest path is
preferred.
med
apply out – affects inbound routes – lower value is
preferred. This is used as a suggestion to an external
AS regarding the preferred route into the As that is
advertising the metric. Don’t forget that the MED can be
overwritten by weight or local pref. same AS
Why laugh at me coming in to go out.
lab10 task7
R1(config-router)#bgp always-compare-med <- this command
forces the router to compare all path, regardless of AS
!
R1(config-router)#bgp bestpath as-path ignore < –
hidden dangerous command. This command was needed also
because as-path and origin attributes are looked at
before the MED.
lab 10 task 8
R1(config-router)#bgp bestpath med missing-as-worst <– any path with no MED value will be treated as the worst path.
Posted in Routing & Switching Lab | Leave a Comment »
How to establish a neighbor relationship with different ip address where there are redundant links to each router.
Posted by Peter Kurdziel on April 6, 2009
Topology
r1 f1/0 <> r2 f1/0
r1 s1/1 <> r2 s1/1
r1
int f1/0 ip add 15.0.0.1 255.0.0.0 int s1/1 ip add 50.0.0.1 255.0.0.0 router bgp 1 nei 15.0.0.2 remote-as 1 nei 15.0.0.2 update-source s1/1
r2
int f1/0 ip add 15.0.0.2 255.0.0.0 int s1/1 ip add 50.0.0.2 255.0.0.0 router bgp 1 nei 50.0.0.1 remote-as 1r1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
31.0.0.1 4 1 8 8 1 0 0 00:04:44 0
r2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
31.0.0.1 4 1 8 8 1 0 0 00:04:28 0
Since 15.0.0.x and 50.0.0.x do not match BGP will not peer with each other, unless you use the update-source command.
Posted in BGP, Routing & Switching Lab | Leave a Comment »
