http://www.youtube.com/watch?v=1rE7oiIQ7fY&feature=player_embedded

Posted by Peter Kurdziel on March 16, 2011
http://www.youtube.com/watch?v=1rE7oiIQ7fY&feature=player_embedded

Posted in BGP, IPV6, Service Provider | Leave a Comment »
Posted by Peter Kurdziel on January 10, 2011
Partial routes – routes that originate in your AS and the AS’s you are directly connected to.
Router bgp (AS number) Neighbor x.x.x.x remote-as (AS number) Neighbor x.x.x.x route-map PARTIALS out
Default route and partial routes that originate in your AS and the AS’s you are directly connected to.
Router bgp (AS number) Neighbor x.x.x.x remote-as (AS number) Neighbor x.x.x.x default-originate !since there is noDefault route only
Router bgp (AS number) Neighbor x.x.x.x remote-as (AS number) Neighbor x.x.x.x default-originate !since there is no default
Posted in BGP | Leave a Comment »
Posted by Peter Kurdziel on September 15, 2010
show ip bgp neighbors <x.x.x.x> advertised-routes
This shows you the routes that you advertised to this peer.
show ip bgp neighbors <x.x.x.x> routes
This shows you the routes you received from this peer that made it through the inbound filters.
show ip bgp neighbors <x.x.x.x> received-routes
This shows you the routes you received from this peer, even those that were denied(filtered).
In order to use this last command you must configure:
bgp <as>
neighbor <x.x.x.x> soft-reconfiguration inbound

Posted in BGP, Troubleshooting | Leave a Comment »
Posted by Peter Kurdziel on July 15, 2010
User Defined Source Port Ranges for PAT Overview
In order for VoIP traffic to not be in violation of the RTP standards and best practices, even/odd pairing of ports for RTP and RTCP traffic for SIP ALG, Skinny and H.323 has been made available.
Following is a scenario of what happens to VoIP traffic translated using PAT without user defined ports.
The first VoIP traffic getting translated using PAT, would request for port 16384 and would get to use port 16384 for its RTP traffic.
The second VoIP traffic stream getting translated using PAT would also request 16384 for its RTP. Since this port number is already in use by the first call, PAT would translate the 16384 source port for the second phone to 1024 (assuming the port was free) and this would be in violation of the RTP standards/best practices.
A third call would end up using port 1025 and others would increment from there.
Each call after the first call would end up having its inside source port translated to an external port assignment that is out of specifications for RTP, and this would continue until PAT binding fir the first call expires.
Problems associated with RTP traffic being assigned to a non-standard port by PAT:
•
Inability for compressed RTP (cRTP) to be invoked in the return direction, as it only operates on RTP flows with compliant port numbers.
•
Difficulty in properly classifying voice traffic for corresponding QoS treatment.
•
Violation of standard firewall policies that specifically account for RTP/TRCP traffic by specified standard port range.
Here is an example from a debug ip nat sip I did:
02:02:14: NAT: SIP: [1] translate embedded port 1029->5060
Here is an example from show ip nat trans:
Pro Inside global Inside local Outside local Outside global
udp 192.1.271:1024 10.1.1.252:5060 192.168.8.13:5060 192.168.8.13:5060
Cisco IOS NAT SIP gateways normally select the next available port+1 for SIP fixup in the NAT translations. The NAT gateway does not check for even/odd pair for RTP/TRCP port numbers, and as a result issues may arise with SIP user agents that are strictly following the encouraged even/odd parity for RTP/RTCP port numbers.
Even port parity for SIP, H.323, and skinny is supported by default and it can be turned off forcing the odd RTP ports allocation.
The following examples shows how to assign a set of ports and associate a map to them.
ip nat portmap NAT-I
cisco-rtp-h323-low appl sip-rtp startport 32128 size 128 appl sip-rtp startport 32000 size 64 ip nat inside source list 1 pool A overload portmap NAT-I
Table 1 Macro Names and Ports
Configuration Examples for Even Port Parity
Even Port Parity: Example
The following example enables even port parity for H.323.
ip nat service allow-h323-even-rtp-ports
The following example enables even port parity for SIP.
ip nat service allow-sip-even-rtp-ports
The following example enables even port parity for the skinny protocol.
ip nat service allow-skinny-even-rtp-ports
source: http://www.cisco.com/en/US/docs/ios/ipaddr/configuration/guide/iad_pat_pt_rng.html
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6640/prod_white_paper0900aecd80597bc7.html

Posted in BGP, Troubleshooting | Leave a Comment »
Posted by Peter Kurdziel on July 5, 2010
BGP neighbor failover taking too long.
Try lowering the timer values. BGP will use the lower value.
Try using neighbor ip-address fall-over [bfd | route-map map-name]
Try using OER/PfR
ICMP Echo Example
The following example, starting in global configuration mode, configures an active probe using an ICMP echo (ping) message. The 10.5.5.55 address is the target. No explicit configuration is required on the target device.
Router(config)# oer master
Router(config-oer-mc)# active-probe echo 10.5.5.55
TCP Connection Example
The following example, starting in global configuration mode, configures an active probe using a TCP connection message. The 10.5.55.56 address is the target. The target port number must be specified when configuring this type of probe.
Router(config)# oer master
Router(config-oer-mc)# active-probe tcp-conn 10.5.5.56 target-port 23

Posted in BGP, Troubleshooting | Leave a Comment »
Posted by Peter Kurdziel on April 19, 2010
Configuring an IPv6 Multiprotocol BGP Peer Group and advertising a route example.
Scenario
Configure R1 & R2 for IPv6 Multiprotocol BGP using a Peer Group and
advertising R1 & R2′s loopbacks.
Simple two router network for demonstration purposes.
R1<—->FR<—–>R2
Configuration
r1
ipv6 unicast-routing
interface Loopback99
no ip address
ipv6 address 2001:DB8:1111::1/48
interface Serial2/0
ipv6 address 2001:DB8:0:CC00::1/48
router bgp 65100
no bgp default ipv4-unicast
neighbor group1 peer-group
neighbor 2001:DB8:0:CC00::2 remote-as 65100
neighbor 2001:DB8:0:CC00::2 peer-group group1
address-family ipv6
neighbor group1 activate
neighbor 2001:DB8:0:CC00::2 peer-group group1
network 2001:DB8:1111::1/48
exit-address-family
r2
ipv6 unicast-routing
interface Loopback99
no ip address
ipv6 address 2001:DB8:1111::2/48
interface Serial2/0
ipv6 address 2001:DB8:0:CC00::2/48
router bgp 65100
no bgp default ipv4-unicast
neighbor group1 peer-group
neighbor 2001:DB8:0:CC00::1 remote-as 65100
neighbor 2001:DB8:0:CC00::1 peer-group group1
address-family ipv6
neighbor group1 activate
neighbor 2001:DB8:0:CC00::1 peer-group group1
network 2001:DB8:1111::2/48
exit-address-family
Verification
R1#sh ipv6 int br
Serial2/0 [up/up]
FE80::C804:12FF:FEDC:8
2001:DB8:0:CC00::1
Loopback99 [up/up]
FE80::C804:12FF:FEDC:8
2001:DB8:1111::1
R2#sh ipv int b
Serial2/0 [up/up]
FE80::C805:12FF:FEDC:8
2001:DB8:0:CC00::2
Loopback99 [up/up]
FE80::C805:12FF:FEDC:8
2001:DB8:1111::2
R1#
sh bgp ipv6 unicast sum
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DB8:0:CC00::2
4 65100 6 6 2 0 0 00:02:17 1
R2#
sh bgp ipv6 unicast sum
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DB8:0:CC00::1
4 65100 6 6 2 0 0 00:02:41 1
R1#
sh bgp ipv6 unicast neighbors 2001:DB8:0:CC00::2 advertised-routes
BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8:1111::1/48
:: 0 32768 i
R2#
sh bgp ipv6 uni nei 2001:DB8:0:CC00::1 adver
BGP table version is 2, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8:1111::2/48
:: 0 32768 i
R1#
sh bgp ipv6 unicast neighbors 2001:DB8:0:CC00::2 routes
BGP table version is 2, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
* i2001:DB8:1111::1/48
2001:DB8:0:CC00::2
0 100 0 i
R2#
sh bgp ipv6 uni nei 2001:DB8:0:CC00::1 routes
BGP table version is 2, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
* i2001:DB8:1111::2/48
2001:DB8:0:CC00::1
0 100 0 i
Troubleshooting
R2#deb bgp ipv6 unicast updates
R2#clear bgp ipv6 unicast * soft
R2#
00:22:50: BGP(1): 2001:DB8:0:CC00::1 send UPDATE (format) 2001:DB8:1111::2/48, next 2001:DB8:0:CC00::2, metric 0, path
00:22:50: BGP(1): updgrp 1 – 2001:DB8:0:CC00::1 enqueued 1 updates, average/maximum size (bytes) 75/75
00:22:50: BGP(1): 2001:DB8:0:CC00::1 rcvd UPDATE w/ attr: nexthop 2001:DB8:0:CC00::1, origin i, localpref 100, metric 0
00:22:50: BGP(1): 2001:DB8:0:CC00::1 rcvd 2001:DB8:1111::/48
Everything is as expected.
More info: Cisco IOS IPv6 Configuration Guide, Release 12.4 Implementing Multiprotocol BGP for IPv6
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-mptcl_bgp.html#wp1027258

Posted in BGP, IPV6, Service Provider | Leave a Comment »
Posted by Peter Kurdziel on January 4, 2010
http://rbcciequest.wordpress.com/2008/02/27/bgp-path-selection/

Posted in BGP | Leave a Comment »
Posted by Peter Kurdziel on October 24, 2009
http://www.nanog.org/meetings/nanog30/abstracts.php?pt=NjIxJm5hbm9nMzA=&nm=nanog30
Posted in BGP, MPLS, VPN | Leave a Comment »
Posted by Peter Kurdziel on August 13, 2009
Why laugh at me applying in out.
Weight – apply inbound to influence outbound traffic.
local-pref – apply inbound to influence outbound traffic.
as-path – apply outbound to influence inbound traffic.
med – apply outbound to influence inbound traffic.
==========================================================
“We Love Oranges AS Oranges Mean Pure Refreshment”
W Weight (Highest)
L Local_Pref (Highest)
O Originate (local originate)
AS As_Path (shortest)
O Origin Code (IGP < EGP < Incomplete)
M MED (lowest)
P Paths (External Paths preferred Over Internal)
R Router ID (lowest)
================================================================
We – weight
Love – local preference
Algorithms – as-path
On – Origin
My – MED
Router – router-id
==============================================================
Discard all Worries before Leaving Rome As the Original Mis-information
Sound’s like a Neighbor’s Idea.
Discard = DISCARD unreachable next hop.
Worries= highest WEIGHT
Leaving=highest LOCALpreference
Rome=Originated on this ROUTER
As=shortest AS_PATH
Original=ORIGIN code
Mis-information=lowest MED
Sound=SOURCE (external or internal)
Neighbor’s=Closet IGP NEIGHBOR
Idea=lowest router ID
==============================
Filtering in BGP-
Request for Proposal – RFP
inbound
1. route-map
2. filter-list
3. prefix-list OR distribute-list
outbound is the opposite.
1. prefix-list OR distribute-list
2. filter-list
3. route-map
Posted in BGP, Routing & Switching Lab | Leave a Comment »
Posted by Peter Kurdziel on June 16, 2009
BGP notes
| Community | Description |
|---|---|
| Local-AS | Use in confederation scenarios to prevent sending packets outside the local autonomous system (AS). |
| no-export | Do not advertise to external BGP (eBGP) peers. Keep this route within an AS. |
| no-advertise | Do not advertise this route to any peer, internal or external. |
| none | Apply no community attribute when you want to clear the communities associated with a route. |
| internet | Advertise this route to the internet community, and any router that belongs to it. |
Do internal BGP (iBGP) sessions modify the next hop?
A. iBGP sessions preserve the next hop attribute learned from eBGP peers. This is why it is important to have an internal route to the next hop. The BGP route is otherwise unreachable. In order to make sure you can reach the eBGP next hop, include the network that the next hop belongs to in the IGP or issue the next-hop-self neighbor command to force the router to advertise itself, rather than the external peer, as the next hop. Refer to the BGP Next Hop Attribute section of BGP Case Studies for a more detailed explanation.
This command is useful in unmeshed networks (such as Frame Relay or X.25) where BGP neighbors may not have direct access to all other neighbors on the same IP subnet.
More info on redistributing OSPF into BGP:
Posted in BGP, Routing & Switching Lab | Leave a Comment »